Skip to content

cleanup: normalize ZERO/ONE constant order in TESTING/EIG error-exit tests#1236

Open
nakatamaho wants to merge 1 commit intoReference-LAPACK:masterfrom
nakatamaho:cleanup/testing-eig-erred-constants
Open

cleanup: normalize ZERO/ONE constant order in TESTING/EIG error-exit tests#1236
nakatamaho wants to merge 1 commit intoReference-LAPACK:masterfrom
nakatamaho:cleanup/testing-eig-erred-constants

Conversation

@nakatamaho
Copy link
Copy Markdown
Contributor

This PR normalizes the declaration and PARAMETER definition order
of the named constants ZERO and ONE across TESTING/EIG error-exit
test routines:

  • {s,d,c,z}errec
  • {s,d,c,z}erred

Specifically, the order is unified to:
ZERO, ONE

This matches the prevailing style used in other parts of LAPACK
and improves consistency for automated translation and maintenance
(e.g., fable-based workflows in MPLAPACK).

No functional changes are intended. This is a pure cleanup.

…it tests

Reorder ZERO and ONE declarations and PARAMETER definitions
for consistency in the TESTING/EIG error-exit test sources.

No functional change intended.
@langou
Copy link
Copy Markdown
Contributor

langou commented Apr 14, 2026

On the one hand, I think LAPACK has been trying to keep alphabetical order when declaring variable.

lapack/SRC/dgeev.f

Lines 209 to 238 in f6fb111

DOUBLE PRECISION ZERO, ONE
PARAMETER ( ZERO = 0.0D0, ONE = 1.0D0 )
* ..
* .. Local Scalars ..
LOGICAL LQUERY, SCALEA, WANTVL, WANTVR
CHARACTER SIDE
INTEGER HSWORK, I, IBAL, IERR, IHI, ILO, ITAU, IWRK, K,
$ LWORK_TREVC, MAXWRK, MINWRK, NOUT
DOUBLE PRECISION ANRM, BIGNUM, CS, CSCALE, EPS, R, SCL, SMLNUM,
$ SN
* ..
* .. Local Arrays ..
LOGICAL SELECT( 1 )
DOUBLE PRECISION DUM( 1 )
* ..
* .. External Subroutines ..
EXTERNAL DGEBAK, DGEBAL, DGEHRD, DHSEQR, DLACPY,
$ DLARTG,
$ DLASCL, DORGHR, DROT, DSCAL, DTREVC3, XERBLA
* ..
* .. External Functions ..
LOGICAL LSAME, DISNAN
INTEGER IDAMAX, ILAENV
DOUBLE PRECISION DLAMCH, DLANGE, DLAPY2, DNRM2
EXTERNAL LSAME, IDAMAX, ILAENV, DLAMCH, DLANGE,
$ DLAPY2,
$ DNRM2
* ..
* .. Intrinsic Functions ..
INTRINSIC MAX, SQRT

In that sense, first ONE then ZERO makes sense to me.

On the other hand, this specific

*     .. Parameters ..
      DOUBLE PRECISION   ZERO, ONE
      PARAMETER          ( ZERO = 0.0D0, ONE = 1.0D0 )

is really not consistent in LAPACK.
Indeed

grep PARAMETER SRC/d*f | grep ZERO | grep ONE

We can see that 176 subroutines uses first ZERO then ONE, and 96 subroutines use first ONE then ZERO.
(Only counting in SRC/ double precision subroutines.)

All in all, I am fine with anything. I am fine going one way, or the other way, or leaving it all as the mess it is. Not everything has to be consistent. But happy to approve the pull request.

@nakatamaho
Copy link
Copy Markdown
Contributor Author

Thanks for the flexibility and for approving.

That said, one thing I’ve learned through this process is that we do need some level of code discipline. Otherwise we keep revisiting the same style/consistency issues in every PR.

My current thinking is:

  • Contributors don’t have to strictly follow all conventions when submitting
  • But changes that move the code toward a consistent style should be accepted

For example:

  • Avoid hard-coded constants like 0.5, -0.125, 1.0D0, 0.0D0
    → use named PARAMETERs such as ZERO, ONE, TWO (and CZERO, CONE for complex)

    This is not just stylistic. It helps:

  • Use LSAME for character comparisons instead of direct comparisons

    This is also not just style. It ensures:

    • case-insensitive behavior consistent with LAPACK
    • portability across compilers and systems where character comparison may differ

To make this explicit and reduce ambiguity, I propose adding a short guideline document (e.g., CODE_DISCIPLINE.md).
This should help reduce friction in reviews and gradually improve overall code quality.

I can draft an initial version if that sounds reasonable.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants